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(54) Abstract Title 

Controlling data flow in a Radio Access Network 

(57) A method of controlling the flow of data. In respect of a given mobile terminal, between a Radio Network 
Controller (RNC) and a NodeB of a UMTS Terrestrial Radio Access Network (UTRAN) where an 
Automatic-Repeat-Request (ARQ) mechanism is implemented between the NodeB and said mobile terminal to 
provide for the retransmission of unsuccessfully transmitted data. The method comprises generating control 
messages at the NodeB and sending these control messages to the RNC, each control message enabling the 
RNC to identify which data should next be sent to the NodeB. 
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1 

Flow Control in a Radio Access Network 

Field of the Invention 

5 The present invention relates to controlling the flow of data in a radio access network of 
a mobile telecommunications network. More particularly, the invention is concerned 
with controlling the flow of data between a NodeB (or Base Stations) and a Radio 
Network Controller of such a radio access network, 

10 Background to the Invention 

The European Telecommunications Standardisation Institute (ETSI) is currently in the 
process of standardising a new set of protocols for mobile telecommimications systems. 
The set of protocols is known collectively as the Universal Mobile Telecommunications 

15 System (UMTS). Figure 1 illustrates schematically a UMTS network 1 which 
comprises a core network 2 and a UMTS Terrestrial Radio Access Network (UTRAN) 
3. The UTRAN 3 comprises a number of Radio Network Controllers (RNCs) 4, each of 
which is coupled to a set of neighbouring Base Stations (BSs) 5 - BSs are often referred 
to as NodeBs. Each BS 5 is responsible for communicating with mobile terminals (or 

20 User Equipment (UE) 6) within a given geographical cell, and the controlling RNC 4 is 
responsible for routing user and signalling data between a BS 5 and the core network 2. 
The interface between the RNCs is referred to as the lur interface, whilst that between 
the BSs and the RNCs is referred to as the lub interface. The air interface between the 
UE and the BSs is referred to as the Uu interface. A general outline of UTRAN is given 

25 in Technical Specification TS 25.401 V3.3.0 (1999-09) of the 3rd Generation 
Partnership Project, 3GPP. 

Under the UTRAN proposals, certain transmission channels (e.g. channels using the 
RLC AM mode) make use of a mechanism known as Automatic-Repeat-Request (ARQ) 
30 to facilitate the retransmission of data packets which are either not received, or are 
received erroneously by a receiving entity, i.e. a UE or a RNC. An ARQ machine exists 
for each Radio Bearer (RB) - RBs being allocated to individual UEs. It will be 
appreciated that the retransmission path, involving as it does passage through a BS, can 
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introduce a considerable delay into the retransmission time and can impact significantly 
on the performance of higher layer protocols (e.g. TCP). 

In order to increase the available peak transmission rate, and to reduce transmission 
5 delays for packet data bearers in order to efficiently support high data rate, a new 
wideband CDMA (WCDMA) downlink shared channel is currently being standardised 
in 3GPP (papers R2-001 120 and R2-001330). This channel is referred to as DSCH-E. 
One of the main features of the DSCH-E is the introduction of a retransmission entity in 
the NodeB (one retransmission entity exists for each terminal using the DSCH-E). The 
1 0 retransmission entity can work either in cooperation with the current ARQ mechanism 
in the RLC entity, or possibly as a standalone ARQ mechanism. In either case, 
buffering will be performed at the NodeB. This new mechanism is known as Hybrid 
ARQ (HARQ). Figure 2 illustrates the signaUing involved in HARQ. 



15 Statement of the Invention 



In a UMTS network, as in current digital networks, mobile terminals will be able to 
roam between NodeBs — this may or may not involve a change in the identity of the 
serving RNC. When a mobile temiinal has to switch between a current and a new 

20 NodeB, the introduction of HARQ and the consequent buffering of data for that mobile 
terminal at the current NodeB requires that a copy of the buffered and unsent data be 
sent from the RNC to the new NodeB - the alternative is that all data buffered at the old 
NodeB is lost. In the former case it is important to minimise the buffer size at the 
NodeBs in order to minimise the duplication of data transmissions. In the latter case, 

25 minimising the buffer sizes at the NodeBs will be similarly advantageous as this will 
minimise the amount of data which is lost. On the other hand, minimising the buffer 
sizes at the NodeBs will reduce the effectiveness of the HARQ mechanism. 



It is an object of the present invention to overcome the disadvantages of the current 
30 3GPP proposals. This and other objects are achieved by introducing a flow control 
mechanism between the RNC and the NodeB in order to limit the buffer size at the 
NodeB. 
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According to a first aspect of the present invention there is provided a method of 
controlling the flow of data, in respect of a given mobile terminal^ between a Radio 
Network Controller (RNC) and a NodeB of a UMTS Terrestrial Radio Access Network 
(UTRAN) where an Automatic-Repeat-Request (ARQ) mechanism is implemented 
S between the NodeB and said mobile terminal to provide for the retransmission of 
unsuccessfully transmitted data, the method comprising generating control messages at 
the NodeB and sending these control messages to the RNC, each control message 
enabling the RNC to identify which data should next be sent to the NodeB. 

10 In certain embodiments of the present invention, each control message identifies 
Protocol Data Units (PDUs) successfully transmitted over the air interface. The control 
messages enable the RNC to know which RLC PDUs have been successfully sent to a 
mobile terminal. The RNC can use this information to delete these sent PDUs from the 
RLC bufTers. 

15 

Each control message may specify an amount of data which the RNC can send to the 
NodcB before a further control message is received. Thus, the NodeB can ensure that 
its buffers do not become too large. This in turn minimises the duplication of the 
sending of data, to an old and a new NodeB, in the event of a handover between 
20 NodcBs. 

Alternatively, a sliding transmission Avindow may be defined at the RNC, the window 
being advanced relative to the RLC buffers each time a control message is received. 
The window is advanced to encompass a sequence of RLC PDUs immediately ahead of 
25 the Jast PDU for which an acknowledgement has been received. 

In a further alternative, each control message places a limit on the number of PDUs 
which may be sent from the RNC without corresponding acknowledgements having 
been received by the RNC. Following the receipt of acknowledgements, the RNC may 
30 send further PDUs imtil said limit is reached, or until a further control message is 
received defining a higher limit. 

Preferably, successfully transmitted PDUs are identified in the control messages using 
sequence numbers associated with respective PDUs. Sequence number may be inserted 
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into PDUs by a flow control protocol which is implemented at the RNC and the NodeB. 
Alternatively, the sequence numbers may be sequence numbers of another protocol 
implemented at the RNC, e.g. by the RLC entity. 

5 According to a second aspect of the present invention there is provided UMTS 
Teirestrial Radio Access Network (UTRAN) comprising at least one Radio Network 
Controller (RNC) and a plurality of NodeBs, each NodeB being arranged to implement 
an Automatic-Repeat-Request (ARQ) mechanism between itself and communicating 
mobile terminals to provide for the retransmission of unsuccessfully transmitted data, 
10 each NodeB being further arranged to generate control messages and to send these 
control messages to the RNC, each control message enabling the RNC to identify which 
data should next be sent to the NodeB. 

According to a third aspect of the present invention there is provided a NodeB for use in 
15 the UTRAN of the second aspect of the invention. 

According to a fourth aspect of the present invention there is provided a RNC for use in 
the UTRAN of the second aspect of the invention, the RNC comprising means for 
receiving said control messages from the NodeBs and for using the information 
20 contained therein to determine which data to send to the NodeBs. 

Brief Description of the I>rawings 

Figure 1 illustrates a conventional RAN architecture of a mobile telecommunications 
25 network; 

Figure 2 illustrates control signalling associated with a HARQ mechanism in the 
network of Figure 1; 

Figure 3 illustrates control signalling associated with a HARQ mechanism in the 
network of Figure 1 including flow control signalling between a RNC and a NodeB; and 
30 Figure 4 is a flow diagram showing a method of flow control between a RNC and a 
NodeB of the network of Figure 1. 

Detailed Description of a Preferred Embodiment 
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The Radio Access Network (RAN) of a UMTS mobile telecommunications network has 
been described above with reference to Figure 1 . The HARQ mechanism for facilitating 
the retransmission of unsuccessfully sent data to a mobile temiinal, and proposed for the 
new DSCH-E charmel, has been described with reference to Figure 1. An embodiment 
of the present invention will now be described with reference to Figures 1 and 3. 

In order to reduce the amoimt of data buffered at a NodeB for a given mobile terminal, 
it is necessary for the RNC serving the mobile terminal to know both how much data 
the NodeB is capable of handling at any given time and which data has aheady been 
successfully sent by the NodeB to the mobile terminal over the air interface. This is 
achieved by introducing a flow control mechanism between the NodeB and the RNC - 
specified using a new protocol identified here as lub+frame handling protocol 
(lub+FH). There remains a need for buffering "above" the NodeB, and this will 
typically be provided at the RLC entity of the RNC. However, bufferings may 
alternatively be done at the Packet Data Convergence Protocol (PDCP) entity. The 
invention may be employed where RLC SDUs are segmented into RLC PDUs of fixed 
size, or where the RLC operates in a transparent mode such that RLC SDUs correspond 
exactly to RLC SDUs. However, the former is assumed to be the case in the following 
discussion. 

The purpose of the lub+FH protocol is threefold: 

1. It enables the RNC to be notified of how much data the NodeB will allow it to send 
to that NodeB at any given time for the mobile terminal (or rather RB) in question; 

2. It enables the RNC to be notified of RLC PDUs successfully transmitted over the air 
interface - this allows the RNC to empty the RLC buffers of corresponding RLC 
SDUs; 

3. It allows the RNC (or PDCP) to transmit data ahready sent to a first NodeB, but 
which has not yet been successfully transmitted over the air interface, to a second 
NodeB in the case of a handover from the first to the second NodeB. 

The protocol provides for the insertion of sequence numbers into RLC PDUs at the 
RNC (by the RLC entity). These sequence niimbers are used by the NodeB and the 
RNC to identify RLC PDUs. When a NodeB receives an ARQ status message from a 
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mobile terminal (containing one or a plurality of ACKs), the NodeB generates a control 
message at the flow control level containing the highest sequence number of the so far 
acknowledged packets. The control message also contains a credit c specifying the 
maximum munber of RLC PDUs which can be outstanding at any given time, i.e. the 
5 number of PDUs which may have been sent from the RNC to the NodeB but for which 
confirmation of successful transmission has not yet been. Alternatively, the control 
message may specify rate at which the RNC can transmit data to the NodeB, i.e. the 
number of RLC PDUs per (predefined) transmission time interval. 

10 Upon receipt of a control message from the NodeB, the RNC proceeds to erase from the 
RLC buffers the RLC SDUs for which PDUs have been successfully transmitted. In 
addition, the RNC deducts the number of currently outstanding RLC PDUs from the 
credit contained in the control messages, and that number of RLC PDUs from the RLC 
buffer: these are transmitted to the NodeB. Before sending further RLC PDUs, the 

1 5 RNC waits for a further control message. 

In the event that a handover arises for a given mobile terminal - this decision being 
made by the Radio Resource Manager (RRM) of the RNC - the RLC buffers contain 
only unsent (or more exactly unacknowledged) RLC PDUs. The RNC will receive a 

20 control message from the new NodeB specifying a number of transmission credits c. 
The control message will not of course contain any sequence numbers identifying 
correctly transmitted PDUs. It is the responsibility of the RLC layer to transfer unsent 
PDUs to the new NodeB. During the handover process, the RRM of the RNC will 
signal to the old NodeB to empty the buffers at the NodeB corresponding to the traffic 

25 channel(s) associated with the mobile terminal and which are to be switched. 

Figure 3 illustrates control signalling associated with a HARQ mechanism in the 
network of Figure 1 including flow control signalling between the RNC and the NodeB, 
whilst Figure 4 is a flow diagram showing a method of flow control between the RNC 
30 and the NodeB. 

It will be appreciated by the person of skill in the art that various modifications may be 
made to the above described embodiments without departing from the scope of the 
present invention. For example, the flow of information from the RNC to the NodeB 
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may be achieved using a "sliding window" at the RNC. The window size W is fixed in 
advance, and at the beginning of a transmission the RNC can transmit up to W PDUs. 
Upon receiving acknowledgements for correctly transmitted PDUs from the NodeB, the 
RLC will then transmit new PDUs so that the maximum number of outstanding 
(unacknowledged) PDUs is no more than W. Preferably the chosen window size should 
be large enough to allow NodeBs to completely utilise the maximum available 
transmission rate. Note that this solution does not require the use of an "Amount of data 
to be transmitted** field of the control messages sent from the NodeB to RNC. 
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Claims 

1. A method of controlling the flow of data, in respect of a given mobile temiinal, 
between a Radio Network Controller (RNC) and a NodeB of a UMTS Terrestrial Radio 
Access Network (UTRAN) where an Automatic-Repeat-Request (ARQ) mechanism is 
implemented between the NodeB and said mobile terminal to provide for the 
retransmission of unsuccessfully transmitted data, the method comprising generating 
control messages at the NodeB and sending these control messages to the RNC, each 
control message enabling the RNC to identify which data should next be sent to the 
NodeB. 

2. A method according to claim 1, wherein each control message identifies 
Protocol Data Units (PDUs) successfully transmitted over the air interface. 

3. A method according to claim 2, wherein the PDUs identified in the control 
messages are deleted by the RNC from the RLC buffers. 

4. A method according to any one of the preceding claims, wherein each control 
message specifies an amount of data which the RNC can send to the NodeB before a 
further control message is received. 

5. A method according to any one of claims 1 to 3, wherein a sliding transmission 
window is defined at the RNC, the window being advanced relative to the RLC buffers 
each time a control message is received to encompass a sequence of RLC PDUs 
immediately ahead of the last PDU for which an acknowledgement has been received. 

6. A method according to any one of claims 1 to 3, wherein each control message 
places a limit on the number of PDUs which may be sent from the RNC without 
corresponding acknowledgements having been received by the RNC and, following the 
receipt of acknowledgements, the RNC sends further PDUs until said limit is reached, 
or until a further control message is received defining a higher limit. 
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7. A method according to any one of the preceding claims, wherein successfully 
transmitted PDUs are identified in the control messages using sequence nxunbers 
associated with respective PDUs. 

5 8. A UMTS Terrestrial Radio Access Network (UTRAN) comprising at least one 
Radio Network Controller (RNC) and a plurality of NodeBs, each NodeB being 
arranged to implement an Automatic-Repeat-Request (ARQ) mechanism between itself 
and communicating mobile terminals to provide for the retransmission of 
unsuccessfully transmitted data, each NodeB being further arranged to generate control 
10 messages and to send these control messages to the RNC, each control message 
enabling the RNC to identify which data should next be sent to the NodeB. 

9. A NodeB for use in a network according to claim 8. 

15 10. A RNC for use in a network according to claim 8, the RNC comprising means 
for receiving said control messages jfrom the NodeBs and for using the information 
contained therein to determine which data to send to the NodeBs. 
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